home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2312 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.9 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Sun, 28 Jan 96 19:37:32 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: Amiga doesn`t need Planar!
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.4a6j@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 27 Jan 96 Michael Van Elst wrote to All:
  14.  
  15.  >> It takes 100*7 reads and 100*7 writes.  The reads are of course necessary
  16.  >> because you wouldn't want to modify the contents 'surrounding' the
  17.  >> vertical line.
  18.  
  19.  MVE> That's not a property of planar displays. It is a property of the
  20.  MVE> Amiga display system.
  21.  
  22. Well I was discussing the Amiga display system mainly.
  23.  
  24.  MVE> Look at the Apple Lisa (probably similar for the original Macintosh).
  25.  MVE> It used a 1 bitplane display and you could write just the 1 bits of the
  26.  MVE> line since your data word was sent to the write-enables instead of the
  27.  MVE> data pins of the RAM chips.
  28.  MVE> Advanced VRAMs support this write-mask technique internally.
  29.  
  30. That's still a lot more work for a 7 bitplane screen, the only thing you don't
  31. need to do is the reads, still 7 writes though.
  32.  
  33.  >> As memory-speed is usually the thing which determines the speed of the
  34.  >> end-result you'll find that the Chunky solution is a factor 14 faster.
  35.  >> (and itcould be worse if I had used 8-bit planar screens).
  36.  
  37. So change that to a factor 7, for non-Amiga planar systems.
  38.  
  39.  >> gives you 2880 LONG gfx-memory-accesses.  Dedicated hardware is a
  40.  >> requirement here as the masking process is quite complex to do with the
  41.  >> CPU.
  42.  
  43.  MVE> That's the point. Chunky is what a general purpose CPU does. For
  44.  MVE> planar you need a CPU (or render engine) that supports planes. You also
  45.  MVE> do not need to read the destination.
  46.  
  47. Yes you do, again talking about the Amiga planar system. The blitter needs to
  48. read the destination, AND it with the inversed Mask, then OR the source data
  49. into it and then write it back to the destination.
  50.  
  51.  >> (ie, no need for a seperate mask!!).
  52.  
  53.  MVE> You don't need a full mask for planar either. You just have to mask
  54.  MVE> the borders.
  55.  
  56. Wrong, I was talking about a cookie-cutted object, and for all you know it
  57. could have contained holes, or whatever.  A full mask is required here.
  58.  
  59.  >> It is notable though that Planar -requires- dedicated hardware to get any
  60.  >> kind of speed, and still manages to perform quite poorly in both examples
  61.  
  62.  MVE> Just because you do not use dedicated hardware.
  63.  
  64. If you take into account the extra effort required to make good use of a deep
  65. planar display then dedicated hardware is likely to reflect upon this.  In
  66. other words it will be more complex, need more memory accesses and in general
  67. it will be slower than chunky hardware at higher costs.
  68.  
  69. The fact that the CPU is well equipped to handle Chunky display hardware is a
  70. huge advantage, as then the CPU can be used to implement tricks not directly
  71. supported in the hardware.  With planar you have to rely on the hardware, if it
  72. gets outdated or you want to do Gouraud shaded texturemapping instead of
  73. old-style plain texturemapping which was supported in the hardware then you're
  74. at a loss, and you'd have to resort to C2P and all that crap.
  75.  
  76.  >> (especially if you take into account that it performs worse even with
  77.  >> less colors than the Chunky examples).
  78.  
  79.  MVE> Some people think that the support for less colors is an advantage.
  80.  
  81. Yes, and I would have agreed with them a few years ago when 8-bit was still
  82. 'too slow' to be usefull.  Now however even 24-bit screens zip along nicely.
  83.  
  84. Most Chunky hardware on the clones however does have a few low color modes
  85. which should reduce the amount of memory used, just like planar can.  The only
  86. thing is that you're limited in your choice of the number of colors a bit more
  87. severly than with Planar.
  88.  
  89.  >> Chunky can VERY easily be handled with the CPU alone, or even in parallel
  90.  >> with a Chunky blitter.
  91.  
  92.  MVE> That's why it is popular.
  93.  
  94. That's also why it is fast and easy to create new (not supported by the
  95. hardware directly) effects with it.
  96.  
  97.  >> Also, even if Planar had
  98.  >> a blitter as fast as the Chunky blitter the planar blitter would have to
  99.  >> move a lot more data to get the same results,
  100.  
  101.  MVE> No. It has to access more data at the borders of the object. That's
  102.  MVE> significant for very low res objects only.
  103.  
  104. See above, I was talking about (real-life) cookie cutted objects, not a window
  105. or something.  The object may contain holes, it may not, and the left/right
  106. border may not even be a straight line.
  107.  
  108.  >> with the CPU alone.
  109.  
  110.  MVE> That's the point. The CPU does not support planar displays. If all you
  111.  MVE> have is the CPU then you want a chunky display.
  112.  
  113. But what reason would anyone have to use planar?  It requires extra
  114. hardware(!!), you limit the CPU as it can do
  115. -nothing- usefull at all when it comes to displaying graphics.  Using Chunky
  116. you get extra hardware as well (although this time OPTIONAL) and the CPU can do
  117. the same tricks the hardware can, and as CPU technology progresses it may
  118. eventually do it faster too.
  119.  
  120.  >> Also ever thought of how easy scrolling is in Chunky?  Planar without the
  121.  >> Copper would be hell to scroll horizontally, while in Chunky it is nothing
  122.  >> more than a copy-loop.
  123.  
  124.  MVE> The copper doesn't scroll anything. The blitter does with a simple
  125.  
  126. Sigh, the copper is the one which loads the horizontal scroll register in most
  127. cases, so it definitely does something.
  128.  
  129.  MVE> copy loop (and a zero cost funnel shifter).
  130.  
  131. Plus a last and first word mask, and it needs to shift in X bits, each at a
  132. different memory location, depending on the number of bitplanes.  See how
  133. complex this is?
  134.  
  135. Grtz John
  136.  
  137. -----------------------------------------------------------------------
  138.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  139. -----------------------------------------------------------------------
  140. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  141.